Modern systems complexity is far greater than the capacity of any single individual. A typical system (as big as an aircraft or as small as a cell-phone) is designed by teams of specialists in some concurrent form. Such teams may include concept engineering, system architects, hardware, software and mechanical engineering teams, manufacturing, reliability, testing and field service experts among others. Each specialist team typically has its own workflow and set of tools. Furthermore, portions of the design process are often outsourced, creating a situation where the various specialists are geographically dispersed and are employed by different companies.
All these teams of specialists need to have a consistent and coherent view of the requirements, the design and the work plans. Design concerns typically cut across multiple disciplines. Consider for example an aircraft design case where the customer requests a particular feature, say an entertainment sub-system, to be installed. This impacts power requirements, alters the weight, requires additional software, hardware and mechanical interfaces and poses new manufacturing, reliability and field service challenges. Because of this interdependency, a design change by any one specialist typically perturbs the design of the whole system.
Therefore, there exists a growing need for collaborative engineering, where multiple teams are working concurrently to refine and optimize a system design. Such work can only be done effectively if each team member has access to up-to-date information. Each team member should be able to assess the impact of his or her changes on the over-all design in order to ensure the design process is converging. These needs are emphasized in cases where team members are geographically and organizationally dispersed.
Moreover, for the design to converge quickly, each specialist needs to understand the effects of a design change on the overall system and needs to communicate the change in unambiguous terms to the rest of the design team. This need is not met by today's design environment for several reasons. Specification, architecture and planning information is typically distributed as text documents and engineering drafts. Such documents are open to interpretation and may contain ambiguities and contradictions. Formal engineering models are domain specific and are not shared between specialists. The software team, for example, has nor the tools neither the expertise to decipher the hardware design in order to detect a change in the SW/HW interface. Information in the form of either documents or formal models is often not shared on line because of lacking IT infrastructure or organizational issues such as mutual distrust between competing vendors for example. Hence critical changes are not propagated in a timely manner.
As a result of these deficiencies, the design process becomes much longer, problems are uncovered at the tail end of the process at integration phase. Recovery is very costly and the resulting design is sub-optimal and often misses some of its goals in terms of target market window, cost, reliability or feature set.
Furthermore, the lack of architecture, structures, and standards for system design and system engineering in general constitutes a major obstacle for the development of systems and often cause significant waste in resources and time which in turn negatively impact the time to market and therefore profitability due to problems in integration of various parts of the system. For example, the lack of architecture, structures, and standards for Electronic System Level (ESL) design and system engineering in general is a major obstacle for the development of automation tools.
In addition, what often worsens the above problems is that a diverse set of engineering tools are used in the process of system design, where each domain specialist is using a particular tool. Engineering tools typically represent a partial model of the design. Such models are formal in some sense—they can execute or simulate on a computer, or have some well understood mathematical foundation. Some examples of this diverse set of engineering tools comprise, for example, SysML tools, such as Rhapsody®, which are used by system engineers to capture an abstract functional description of the design, Simulink which is used by DSP, control, and algorithm designers to capture computational aspects of system components, reliability analysis tools, such as Relex®, which are used by reliability engineers to capture system possible failure modes and reliability predictions, structural modeling tools, such as Pro-Engineer® and SolidWorks®, which are used to model and construct the structural elements of a system, and analysis tools, such as ANSYS® and Abacus®, which are used to numerically analyze the mechanical and electromagnetic aspects of a system.
Such engineering tools can typically export their internal models to a domain specific format, often as a computer file. The formats tend to be all different, as are the underlying semantics of the different models. Moreover, design information needs to be shared among the various design teams and specialists doing the design. Building on the examples above, the structural information captured in a SysML model is required for the reliability analysis process. The assumptions about input/output relationships in a control algorithm design must be consistent with the SysML representation of communication between components. Furthermore, certain properties of the overall system can not be observed in any of the design tools because they may constitute emergent properties that only show up at the full system level. For example, two control algorithms that operate flawlessly when observed independently may nonetheless oscillate due to a non-obvious feedback loop when these two control algorithms are coupled together using, for example, the system level communication model.
The current approaches to address the above problems have their own drawbacks. For example, the WebDAV is arguably one of the most widely used synchronization scheme. WebDAV does not, however, address the need to co-synchronize data and program(s) among various design teams collaborating on the same system design.
Thus, it is an objective of various embodiments of the present invention to provide a model exchange scheme which synchronizes both the data and program aspects for the purpose of system design. In various embodiments, this method or system of synchronization of both the data and the program aspects, when optionally combined with user identification, access rights management, and automatic notification, addresses one of the most sever bottlenecks in system design as described above.